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Mobile edge computing (MEC) is a new computing paradigm that brings 
cloud services to the network edge. Despite its great need in terms of 
computational services in daily life, service users may have several concerns 
while selecting a suitable service provider to fulfil their computational 
requirements. Such concerns are: with whom they are dealing with, where 
will their private data migrate to, service provider processing performance 
quality. Therefore, this paper presents a trust evaluation scheme that 
evaluates the processing performance of a service provider in the MEC 
environment. Processing performance of service providers is evaluated in 
terms of average processing success rate and processing throughput, thus 
allocating a service provider in a relevant trust status. Service provider 
processing incompliance and user termination ratio are also computed during 
provider’s interactions with users. This is in an attempt to help future service 
users to be acknowledged of service provider’s past interactions prior 
dealing with it. Thus, eliminating the probability of existing compromised 
service providers and raising the security and success of future interactions 
between service providers and users. Simulations results show service 
providers processing performance degree, processing incompliance and user 
termination ratio. A service provider is allocated to a trust status according 
to the evaluated processing performance trust degree. 
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1. INTRODUCTION 


Mobile edge computing (MEC) is a new emerging technology that extends the cloud computing 
capabilities to the network edge [1], by integrating MEC servers with the mobile network edge [2], through 
radio access network (RAN) [3], [4]. This permits direct mobile communication between the base network 
and end users [5], which allows low latency, better quality of service (QoS) [6], high bandwidth access to 
mobile applications and network information [7]. With the great evolution of mobile devices’ capabilities, 
their owners hold valuable information, apart from the devices’ configuration, such as real time knowledge 
and on-time location awareness of an event. Such mobile capabilities and information are considered great 
resources in terms of data analysis, processing, and storage media [8]. With the MEC network expansion [9], 
there is a great increase in service providers offering services. In this context, there could be different service 
providers offering similar service types, e.g., processing computation and/or storage, were each of them 
could have different processing performance quality. On the other hand, one service provider could offer 
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more than one service type [10]. However, not all services offered by the same service provider could have 
the same processing performance efficiency. Meanwhile, service users could require different functionalities 
and have different processing preferences, in terms of cost, storage capacity, processing performance quality 
and trust degree [11], [12]. 

Given that, service providers are located in remote locations, most of them are unknown to service 
users. For this reason, service users hold several doubts such as, dealing with unknown service providers, 
user’s data privacy, service providers’ history and processing performance quality. This is mainly due to the 
lack of previous experience between service providers and users. This creates a level of uncertainty about the 
fulfilment of service users’ various computational needs and expectations, which limits users’ dependency on 
the MEC resources [13]. Many researchers had presented various attempts to build trusted relationships in 
edge computing paradigms [14]. This is to provide an efficient trust evaluation scheme for the available 
services provided by service providers, to secure future users’ interactions [15], [16]. In mobile edge 
computing, a secure multi-tier model was proposed in [17]. In this protocol, it was assumed that the higher 
degree of trust, the less security measures could be taken by a node and vice versa. But unfortunately, it did 
not consider sudden attacks occurring for a trusted node, such as hacking. A trust evaluation scheme was 
presented in [18], were it computes service providers’ identity, hardware capabilities and behavioral trust in 
the MEC network. The main limitation of this scheme is that it mainly depends on users’ feedback opinion to 
compute trust. 

An integrated trust evaluation model was depicted in [19], to evaluate service providers’ identity, 
historical behavior and quality of service offered. Trust computation was time consuming in this model, due 
to the complexity of the equations. In [20], a trust assessment protocol was developed that monitors and 
analyze traffic flow of interactions between service users and providers to evaluate trust. However, no 
performance parameters were evaluated. Another attempt to evaluate service providers’ performance during 
their interactions is the issuance of a service level agreement (SLA) [21]. An SLA is an agreed upon 
document between a service provider and user, that specifies the required task description and application 
requirements [22]. Yet, this is not sufficient to secure service users, since not all service providers abide to 
the SLA statements thoroughly. However, there is a lack of a standard SLA format. As shown, each of the 
previously mentioned protocols measured cloud services using different parameters. There is not a unified 
scheme that could evaluate service providers processing performance. Meanwhile, node history was not 
captured, which gives a chance for an entity to behave maliciously, knowing that it would not be recognized 
in the future. This increases service users’ fears and prevents them from relying on the cloud and edge 
computing paradigms to fulfil their computational needs. 

This paper presents a unified trustworthy evaluation model that evaluates service providers’ 
processing performance, to distinguish trustworthy providers. The main contributions of this paper are: 
i) service providers’ processing performance evaluation in terms of processing success ratio and throughput, 
ii) processing incompliance and user termination ratio computation of service providers, iii) development of a 
penalty system to track malicious actions committed by service providers, and iv) assignment of service 
providers to relative trust status. This would help service users in their service providers’ selection and 
optimizes the security of future interactions, which enhances the MEC network expansion [23]. 

The rest of this paper is organized as follows; section 2, introduces the proposed architecture 
method, functional algorithms, and their description. Section 3 shows the results and discussion. Finally, the 
conclusion and future work are presented in section 4. 


2. PROPOSED ARCHITECTURE METHOD 

The proposed architecture evaluates the processing performance of service providers in the MEC 
network. In this model, a service provider is evaluated according to its processing performance quality and 
not by the quantity of hardware or software resources that it possesses, e.g., storage space, number of 
processors and RAM. The main protocol entities, proposed functions, equations, and algorithms are 
described in subsection 2.1 to 2.6. 


2.1. Main protocol entities and their equivalent tasks 
The main acting entities in the proposed scheme are service provider SP, service user SU, cloud 
broker (CB), network provider (NP) and cloud service manager (CSM) [24]. The relationship between the 
protocol entities is shown in Figure 1 and detailed below. 
— Service provider SP: [25] a service provider “i”, i € I, where I is the set of service providers. A service 
provider may be a small entity offering one service of one type, or a big organization that owns several 


hardware and software resources and offers several services of different job types. In case a service 


Int J Elec & Comp Eng, Vol. 12, No. 2, April 2022: 2121-2138 


Int J Elec & Comp Eng ISSN: 2088-8708 O 2123 


provider SP, provides more than one service type, it is referred to as Sr;. For simplicity, we will be referring 
to each service provider as Sr;, throughout this paper. 

Service user SU;: a service user “j”, j € J, where J is the set of service users. A service user could be an 
entity or organization that requests a specific service to be performed over the network and pays for it [26]. 
Cloud broker CB,: a cloud broker “u”, u € U, where U is the set of cloud brokers. CB is an entity that 
mainly helps service users to find appropriate service providers to fulfil their computational needs, and it is 
being paid for this job. CB works as a local entity per area, where it should be aware of all available service 
providers and their offered service type. CB could communicate with other entities outside its area to reach 
suitable service providers [22]. CB is considered as a semi trusted entity that is not allowed to reveal 
service provider or service user private information, such as own opinion, as it could have a personal 
benefit. It also acts as a transmission and storage medium between service provider, user and CSM for 
certain encrypted information as shown below. 

Cloud service manager (CSM): is considered a fully trusted authorized entity that is responsible for 
registering cloud brokers, service providers and service users to the MEC network through a network 
provider. CSM evaluates the processing performance and trust status of service providers [27]. It also 
checks the status and validity of cloud brokers periodically to ensure secure communication medium 
between service providers and users. Therefore, CSM should maintain high computational capabilities and 
covers a wide geographical region. 

Network provider NP,: a network provider “w”, w € W, where W is the set of network providers. NP is 
responsible for communication, data transmission and network efficiency, between all the above entities. 
Note that, there could be more than one network provider located per geographic area [12]. 


Forwards registration 
request of CB or Sr 


Registered CB or Sr 


Requests 
registration to 

MEC network- 
Function F0 


Registered Sr 


Request Job- 
Function F1 


Selected Sr 


~% 
Searches for me SQ z 
suitable Sr N ase | 


Figure 1. Main protocol entities relationship 


However, a cloud broker, service provider or service user could deal with more than one network 


provider [28]. While a service provider could accept jobs from more than one cloud broker, a service user can 
also deal with more than one cloud broker to request different computational tasks. All of the above entities 
are authenticated in the MEC network by their unique identity, which is out of the scope of this paper. 


2.2. List of assumptions 


a) 


b) 


c) 


d) 


The proposed scheme considers the following assumptions: 
There are three job types requested over the MEC network; type 1: storage request (storing massive 
terabytes, e.g., videos), type 2: computational processing request (jobs that require high processing 
speed/capabilities), type 3: requesting both of them. These jobs are the most commonly requested 
processes in the cloud computing paradigm and MEC network; 
If the same service provider SP; offers more than one job type, known as Sr;, were r € {type 1, type 2, 
type 3}. This does not mean that SP has the same computational efficiency for all job types. For instance, 
it could be powerful in one job type, e.g., storage, and weak in another, e.g., processing efficiency or vice 
versa; 
The same service provider SP; gives equal usage and benefits of its hardware and software resources to 
all its services and users; 
Job processing, storage and execution isolation is considered as a default action by a service provider 
[29]; 
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e) Since each service user could have different priorities and intentions, the proposed scheme asks the 
service user for a priority list of preferences and responds with a recommendation list accordingly; 

f) Batch processing is assumed for trust computation. All processes of the same job type per service 
provider Sr; are gathered per computational interval (e.g., month); 

g) Trust evaluation is performed per process accepted by Sr;; 8) A network provider of each of Sr;, SU; and 
CB,,, have a limited contribution in the proposed scheme as discussed below. 


2.3. Processing performance computational equations 

The proposed trust scheme measures the processing performance P(S7;) of service provider SP; 
which could own more than one service Sr;. However, jobs of the same type, are evaluated per service 
provider S7;, as mentioned previously. Noting that, P consists of different weighted parameters and computed 
by the CSM, as described below. 

Let each requested job of any type be known as process “a”, a € A, where A is the total number of 


6699 


processes executed at Sr;, but distinguished by their job type. Each process “a” has a separate service level 
agreement, even if it is performed by the same SP;/Sr;. Assume the components of an SLA of process “a” 
executed by Sr; be processing cost (SC;,), storage capacity GB/TB (SS;,), duration of maintenance hr/min 
(SMia), and agreed estimated execution time hr/min (SEa) [30]. All SLA’s components are rated by SU; 
after the job is ended or terminated [31]. The proposed scheme constitutes of eight equations, as detailed below. 


Let T, be actual processing execution time of process “a” at Sr;, where “a” start time is Past and end 
time is Paet. Hence, 


T,= Paet ag Past (1) 


Assume the time difference between the estimated agreed time SE;, and actual processing execution time T,,, 
be TR;, (Time compliance), therefore, 


TRig= SEia _ Ty (2) 
TR, = E 0 "a" completed within | 
ia“ 1<0  SEia time incompliance 


66,99 


Given that each process “a” should end in one of the following four states {Pg1, Pez, Pri, Pro}: 


Pg; Process ended by Sr; complete 
i Process ended by Sr; incomplete 


Pr; Process terminated by SU; Ty > SEia 
Pr2 Process terminated by SU; Ty < SEia 


Let Pey_T,Pg2_T,Pr,_T and Pr2_T be the total number of Pr,, Pez, Pra and Pro respectively. Let 
the rated SLA, be SLA;,_R, and the total number of SLA;,_R implies the total number of ended 
jobs/processes, “A”. Therefore, the average processing success rate Pyy (Sr;) can be measured by, 


Pay (Sr) = = (3) 
On the other hand, processing incompliance PI(Sr;) or failure ratio, can be calculated as, 

PI(Sr;) =“ (4) 
The user termination ratio UTR(Sr;) can be measured by, 

UTR(Sr,) = 22 (5) 


In case UTR(Sr;) exceeds a certain threshold, a warning is issued to alarm the relevant service 
provider of its high user termination ratio. The processing throughput PT(Sr;) will be measured by 
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considering the number of completed successful processes P;,, per computational interval and given certain 


points for each range of values by, 


PT(Sr;)= Points(S7;) (6) 
for 1<P,,_T // Function F3. 

After all, the processing performance of a service provider P(Sr;) will be computed as, 

P(Sr;) z Pay (Sri)+ PT(Srj) (7) 


2 


Noting that the total number of processes executed, “A”, at service provider Sr; of SP;, per computational 
interval, equals; 


A = Pga -T +Pg2_T+Pri-T+Pr2_T (8) 


as process “a”, should end in one of these four states. The processing capacity PC; of a service provider Sr;, 
is a predetermined value by the service provider specified during the registration process. Each of the above 
equations is applied in the below functional algorithms, as part of the trust computation process. 


2.4. Functional algorithms and description 

The proposed protocol is composed of eleven functional algorithms, which leads to measuring the 
processing performance of a service provider Sr; and assigning it to a trust status. It also measures the 
processing incompliance and user termination ratio per service provider. A penalty system is also presented 
to identify any malicious action performed by the participating entities. Table 1 shows each function name 
and aim, the consequent action performed with the relevant algorithm figure number. Figure 2 presents the 
protocol architecture and the relationship between the eleven functions. Dashed lines indicate that this 
function may or may not be called. 


Table 1. Proposed scheme functions 


Function Aim Action performed Algorithm 
name no. 
FO Service provider registration Service provider registered to MEC network if it is not 1 

function. previously registered in network. 
F1 Job request and execution Job processed by service provider. 2 

protocol. 
F2 Cloud broker computation of total “A” computed per service provider Sr;. 3 

SLAjg_R, “A” for each service 
provider S7;. 
F3 Processing throughout PT(Sr;) computed. 10 
computation for each Sr;. 
F4 Processing performance P(Sr;), PI(Sr;), Sr;_age, UTR(Sr;) & Pay (Sri) computed. 9 
evaluation for S7;. 

F5 Trust status computation function Ta (Sri) computed. 11 

for Sri. 
F6 Cloud broker checks SLAjg_R Penalty E1_SU,; is set to true or false accordingly. 4 

validity. 
F7 Complain function against service Cloud broker stops sending new job_request to Sr; until TRia 5 

provider S7;. correction is sent by it. 
Penalty Functions 
El SU; did not send SLA;,_R. All job requests by SU; are rejected until it sends SLAjg_R. 6 
E2 Sr; attempt to register again as a P(Sr;) is decreased in the first attempt. While Sr; is temporarily 7 
new provider in the network. blocked from accessing the network for X-days in the later 
attempts by penalty “ES”. 

E3 Lazy or compromised cloud Generates W1 or W2 in the first and second attempts. While 8 


broker. 


CB, is temporarily blocked from accessing the network for X- 


days by penalty “E4”. 


2.5. Proposed penalty protocol 


The penalty protocol is presented as part of the proposed architecture. It mainly aims to track service 
providers malicious actions, which helps in their processing performance and trust status computation 
process. However, the penalty protocol achieves the following: i) it shows the type of wrong action 
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performed by the involved entity; ii) it encounters several malicious action types expected to happen, such as 
an existing service provider attempt to register as a new one, in order to hide its bad history; iii) it counts the 
number and type of malicious actions performed per computational interval; and iv) imposes a penalty 
according to each malicious action type performed by the accused entity. 

The penalty scheme also monitors cloud brokers and service users’ actions in a limited manner, 
since this is out of the scope of this paper. This provides more secure transactions between service providers, 
users, and cloud brokers in the MEC environment. Table 2 states each penalty name, its description, and 
consequences. All of the above functions are described in the following subsections with their relevant 


algorithms. 
Function-F0 Penalty Function-E2 
Sr; registration Sr; Re-register 
attempt 
Penalty Function-El 
Function-Fl lazy SU; 
Job requested by SU, 
and executed by Sr; 1 
Function-F6 
Checks SLA;, R 
validity 
Function-F2 
Cloud broker J 
computation Function-F7 
= Complain function 
against Sr; 
17 Penalty Function-E3 
Function-F4 --! Compromised CB,, 
Processing performance 
computation 
Function-F3 
Processing throughput 
computation of Sr; 
Function-F5 
Trust Status 
computation of Sr; 
Figure 2. Functions relationship diagram 
Table 2. Penalties and their consequences 
Penalty name Description Consequences 
SU; did not send to CB, rated(SLA;,_R) after process Job request rejected until sending the pending 
El_SU; : 
ended/terminated. SLAjg_R. 
E2_S7; Sr; first attempt to register again in the MEC network. Request rejected, P (Sr;) decreased. 
E3 CB Cloud broker CB,, exceeded end of month batch computation for Cloud broker receives warning W1 or W2 from 
ii Sr; for one or two attempts. CSM accordingly. 
Third attempt of cloud broker to delay its computational job, Cloud broker is temporarily blocked from the 
E4_CB, : «pg» . 
after being warned by “E3”. Compromised CB,. network by CSM. 
E5 Sr Sr; second attempt to register again in the MEC network, after Service provider is temporarily blocked from 
e being warned by “E2”. Compromised Sr;. the network by CSM, for X-days. 


2.6. Functional algorithms 

In this section, each of the above mentioned functions in Table 1, are described below with their 
relative algorithms. The penalty functional algorithms are also detailed below, together with their generated 
warnings, and actions performed accordingly. 


2.6.1. Service provider registration 


A service provider SP; could own more than one service, thus service registration to the MEC 
network is performed per service Sr; {job type 1, 2, or 3} of service provider SP;, with the aid of a network 
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provider. Algorithm1, shows the service provider registration algorithm 1, function FO, and its flowchart in 
Figure 3. 


SP, sends to NP,, join_request of Sr; 


NP „sends to CSM join_request of Sr; of SP; 


CSM checks if 
Sr;is previously 
registered 


Execute Penalty 
Function E2 


CSM issues identity_Sr,, computes 
P(Sr;), T, (St), STi piren STi ages POLST) 


CSM sends to NP,,, and NP,, sends to Sr;: 
[identity_Sr,, P(Sr;) = 0, T, (S1,)=0, 
ST; piven STi ages PC AST, )] STi pu 


NP „ sends to >CB,,: new Sr;, job_type, 
PC(Sr:) 


Figure 3. Service provider registration flowchart 


Algorithm 1: Service provider registration-function FO 

Algorithm code: F0 

Description: Service provider registration function. 
Executed at CSM. 

1. Input: new Sr; of SP;needs to register to MEC network. 


2. Output: registered Sr; of SP. 
3. SP;9NPy: join_request of Sr; of SP; 
4. NP, >CSM: join _ request of Sr; of SP; , 
5. where join request includes job type = (storage, processing, or both & PC; value) 
6. CSM: checks E E 
7. if Sr, exists then 
8. execute Penalty Function E2 
2 exit () 
1 else 
A CSM: 
3s issues identity Sr; // Sr; unique credentials 
4. computes i 
5. P (Sri)=0, To(Sri)= “Beginner”, // T,(Sri)= initial trust status of Sr; 
6. assigns PC; (Sr,;)=value 
STi biren = Current_date, // birth date= registration day 
9. STi age= 0 // initial state // age of Sri 
20. CSM>NP,: 
2T; NP, >Sr;: (En (identity Sri, P (Sri) = 0, T, (Sr;)= 
n “Beginner”, ST, pirtwSTiager PCi (Sr:)) SPipu) 
24. //encrypted by the public key of SP; 
25. NP,>CB,: new Sr;+ job_type+PC; (Sr;) 
26. // NP,informs CB, of new Sr 
endif 
27. end 
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By the completion of function FO, a new service Sr; of service provider SP;, is now registered to the 
MEC network, with a unique identity number to be authenticated and distinguished among other service 
providers. Service provider’s unique identity is issued and saved by the CSM. On the other hand, a network 
provider should have a list of all available registered service providers and must exchange it with other 
network providers, if any exists, within the same region. A network provider also must continuously update 
cloud brokers with the newly registered or deactivated service providers. Cloud brokers by return, will be 
aware and updated with service providers’ status in their own area, which enhances service provider selection 
process by users. This minimizes the communication overhead between the participating entities in the MEC 
network. 


2.6.2. Job request scenario algorithm 

Algorithm 2, shows the job request scenario algorithm steps. A service user is expected to request 
one of the previously mentioned job types from a cloud broker, which in return searches for an appropriate 
service provider. If SU; did not send rated SLA for its previously ended job in the MEC network, this user is 
penalized by being prohibited from requesting further jobs through function E1, described in section 2.6.4, 
until it sends the required rated SLA. Otherwise, CB, asks SU; to choose from a priority list its preferences, 
as shown in algorithm 2. Upon SU; feedback, CB, sends a recommendation list of available service 
providers, with respect to the chosen priorities [32]. SU; chooses a service provider and informs the CB, of 
its choice. 

Consequently, CB, checks the chosen service provider processing capacity PC;(S7;) limit. If 
PC;(Sr;) is not maximum, the cloud broker starts direct communication between the service provider and 
user. Given that, each job will have a separate SLA, chosen Sr; sends an initial SLA, SLA;,_I, to SU; for 
approval. Upon SLA approval by both parties, requested job processing starts, were Sr; informs SU; of the 
job start time; Pa,,. Job processing is ended or terminated in one of the previously mentioned four states, 
(Pei, Pez, Pra, Pr2) by either the Sr; or SU;. Consequent steps take place accordingly as stated in Figure 2. In 
all cases, SU; should send rated SLA;,_R. 

While TRj, (time compliance, equation 2), is computed by Sr;, it should be approved by SU, within 
a time threshold, to avoid holding an opened transaction for a long time intentionally by any entity. In case, 
SU; requests TRjg correction, Sr; should reply with the corrected TRj,within a time threshold, otherwise 
complain function F7 (detailed in section 2.6.3) is called. Upon TR;,, agreement, function F6 (algorithm 4) is 
called to check the validity of rated SLA;,_R (depicted in section 2.6.3). The rated SLAjg_R is encrypted by 
the public key of the CSM, which will handle trust computation process. This is performed using asymmetric 
encryption techniques, such as public key infrastructure (PKI) [33]. Using PKI, ensures secure trust 
computation, information integrity and confidentiality, while securing future user interactions [34]. 


Algorithm 2: Job request processing scenario-function F1. 
Algorithm code: F1() 

Description: Job Request and Execution Protocol 
1s Input: job_request by SU;. 


2. Output: job_request of SU; executed. 
Si SU; >CB, ?job_request = job_type: (storage | processing | both) 
A: CBy,: checks 
5. if E1_SU,; = true then 
F execute Penalty function El // lazy SU; 

i exit () 
Bis endif 
9. CB, >SU;: priority list of job_type 

0. where priority list = (P(Sr) | storage capacity) 
1. SUCB,: returned priority list answer 

2y CB,DSU;: recommendation_list of Sr; with respect to priority list answer 
3. SU;>CB,: chosen Sr; 

4s CB,: checks 

5. if PC(Sr,) = maximum then 

6. chosen Sr, rejected 

is return to step 12, excluding chosen Sr 

i else 

9. CB,>Sr;: job_request of SU; 
20 endif 
21 Sr : 
= if Sr, refuses job request then 


Sr,>CB,: job request rejected 
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24. return to step 12, excluding chosen Sr; 

25. else 

26. Sr, >SU;: SLAial for approval 

2s where SLAjg_I = (SEiarSCiarSMiar SSig) // initial SLA 
28. SU; >CB,: SLAial 

29. endif 

30. CB,: 

31 


if SLAia l = approved then 


a CB, >Sr,: approved SLA;,_I 
34 ` else 
i return to step 12, excluding chosen Sr; 
SDs , 
endif 
36. Sr: assigns 
37. job_type of SLAial to “a” 
38. issues Pag 
Bos Wan 


where Pay,=(start_date time of process “a”) 
40. SSU: Pay // informs SU; of start of processing 

Case 1: Service provider ends job request 

41. Sr;DSU;: Pg 


42. where Pg = Ppl Pez= (Paet,TRigr Ty, Paet Past) 

43. & Paa= (end date & time of process 4a,) 

44. SUj: checks // within time threshold 

45. oF T, = approved then 

46. SU; CB: (En (SLAia-R) CSMpy), 

47. where (SLAia R) = rated(SEiq, SCig, SMiar SSig)+ TRig_true+Pr, | Pro 
48. execute Function F6 

49, else // TRig false 

50. SU;>Sr;,: requests TRjg correction, 

= wait for corrected Pr, 


if received within time threshold then 


53. return to step 44 

54. else 

DS: execute Function F7 // complain function against Sr 
36; endif 

Pi endif 


Case 2: Service user terminates job_request 
58. SU; PSN; : Pr 


59. where Pr = Pr, | Pr2= (process termination request) 

60. Sri: 

61. computes T, & TRig 

62. Sry>SU;: T, & TRia 

oa SU): checks 

65. if T, = approved then 

66. SU; >CB,: (En (SLAia-R) CSMpy), 

67. where (SLAjg_R) = rated(SEiqg, SCiar SMiar SSig)+ TRig_true +Pry|Pr2 
execute Function F6 

68. else // TRig_false 

69. SU;>Sr;: requests TRia correction, 

os wait for corrected Pr, 


if received within time threshold then 


: return to step 63 
73. else 
74: execute Function F7// complain function 
75. endif 
VG: endif 
77. CB,: executes Function F2 
78. endif 
gie end 


Upon the completion of function Fl, CB, gathers all rated SLAs of Sr;, per computational interval 
and starts its computation process as described below. 


2.6.3. Cloud broker computational algorithms 

Functions (F2, F6 and F7) are executed by the cloud broker, as explained below. In Function F2 
presented in algorithm 3, CB,, is responsible to collect all the rated SLA;,_R per Sr;, counts and sends them as 
a batch of rated SLA’s (SLA;g_Rn) to the CSM periodically for trust computation. This batch is sent 
encrypted by the public key of the CSM and stamped with the date of F2 function execution “Y dia”. 
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Algorithm 3: Cloud broker computational-function F2 
Algorithm code: F2. 
Description: Cloud broker computational function. 
Executed by the cloud broker. 
Input: Ep (SLA;g_R) CSMp, per Sri 
Output: Batch of (En (A, SLAia Rn) CSMp,) + Ydig per Sri // Ydia date of computation 
let (En (SLAjg_R) CSMp,) be referred to as SLAia Rn 
CB,: 

A= count SLAjg_Rn 

assign Ydia to current_date 
CB, CSM: Batch of (E, (A,SLAia Rn) CSMp,) + Ydia 
end 


a ADU PWN EH 


Algorithm 4 of Function F6, is called by function F1, where CB, checks if SU; had sent rated SLA 
of its last transaction. If not, then CB, executes penalty function E1 to penalize SUj, for its laziness. Function 
F7 presented in algorithm 5, is called by function Fl, where a CB, checks whether Sr; had sent corrected 
TRig or not, within a time_threshold. If not sent, CB, broadcasts message Mrp accordingly to all network 
providers, in order to stop dealing with the relevant Sr; until sending corrected TR;,. The network provider 
broadcasts Myg to other cloud brokers as stated in algorithm 5. 


Algorithm 4: Cloud broker checks SLA_R validity 
Algorithm code: F6 

Description: Cloud broker checks SLAR. 
Executed by cloud broker. 


1. Input: SLAia R 

2. Output: El SU; = true or E1_SU; = false 

Sou C Bers 

4. if SLAjgR = null then // did not send SLAia R 
5. generate E1_SU; = true 

6 execute Penalty function El 

7 else 

8 El_SU; = false 

9. endif 

10. end 


Algorithm 5: Cloud broker complain function against service provider 
Algorithm code: F7 

Description: Complain function against service provider. 
Executed by cloud broker. 

1. Input: TRjg correction=null. 

2. Output: Cloud broker stops sending new job request of any 
3. SU; to Sri. 

4. CB ,>Sr;: requests TRjg correction 

5.CB,: stops sending new job request to Sr; until TRig 

6. correction sent E 

7. CB,>NP,: broadcast Mrr 

8. where Mrpr= (pending TRig correction, no new 

9. job_requests) 

10. NP,>CB: broadcast Mrr 

11. end 


2.6.4. Penalties computational algorithms 
Three penalty functions (E1, E2, E3) introduced in algorithms 6, 7 and 8 respectively, are described 
below. Algorithm 6 describes penalty function E1, which is called by function F6, in case SU; did not send 


rated SLA;_R. In this function, a network provider broadcasts warning message M,,, to all cloud brokers, to 
warn them not to accept any job requests from SU; until sending the rated SLA;,_R as shown in algorithm 6. 


Algorithm 6: Penalty function E1 

Algorithm code: El. 

Description: Service user denied sending rated SLA. 
Executed by cloud broker. 

1. Input: E1_SUj=true. 

2. Output: requests SLAia R, job _request rejected 
3... CB, 

4 job_request rejected of SU 
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CB,>NPy (SU;): Msta 

where Msıa= (pending SLAia-R, job _ request rejected) 
NP, (SU) > CB: broadcasts Mga to nearby CBy, V u, 
CB> SU;: E1_SU;, requests SLAjg_R 


COND 


end 


Algorithm 7 presents penalty function E2, were it’s called by function FO, in case CSM discovers 
that a previously registered S7;, is trying to register as a new provider to the MEC network. Hence, CSM 
imposes penalty E2, which decreases Sr; processing performance value, in the first attempt. In case this 
action is repeated again, malicious Sr; is temporarily blocked from accessing the MEC network by penalty 
E5. Consequently, CSM sends warning message M, to the involved CB, and requests from it to find a 


replacement service provider, to delegate malicious Sr; tasks to a newly selected provider. CB, broadcasts 
this message to other cloud brokers and service providers, in order not to deal with malicious service provider 
temporarily. 


Algorithm 7: Penalty function E2 

Algorithm code: Penalty function E2. 

Description: Service provider re-register attempt to MEC network. 
Executed by CSM. 

1. Input: E2_ Sr; 

2. Output: P(Sr;) decreased or system temporarily block for accused Sri. 
3s CSM: 

4 join_request rejected 

5i generate E2_(Sr;) // Penalty E2 
6. count E2_Srj++ 

7 if E2_Sr,; =1 then 

8 P (Sr;)= P (Sr;)-0.01 

9 execute function F5 


0; CSMPCB,, PSr; : (En(P (Sri), Tn (Sri) STip,,) 

id, elseif 
12. E2_ Sr; > 1 then 

3° generate E5 Sry, // system temporarily block from the network of 


Sr for X-days 
4 CSM>CB,>Sra : E5_ Sra 
5 CSM>CB, (Sri): requests new Sri selection|| My 
6. where My=[compromised Sry] 
7 CB, (Sri) > CB & Sr: broadcasts My to nearby CB, & Sry, Vi & u 
8 CBy: selects Sri 


9. CB,> Sri: job_delegation_request || M 


y 
20. where job delegation _request=(job_request) 
Dil: endif 
22. end 


On the other hand, penalty function E3, shown in algorithm 8, is called by function F4, in two cases; 
casel: a CB, postpones sending the total number SLA;g_R, “A”, per Sr;; case2: CB, adjusts its computation 
time (Ydjq) as a malicious action, during its processing of function F2. In both cases, the CB, is claimed to 
be accused. CB,, is warned by warning number “W1”, and a message is sent to it by the CSM. If one of these 
actions is repeated again, CSM sends warning number “W2” to the accused CB,,. If the CB, performs any of 
these malicious actions for the third time, then penalty E4 is imposed by CSM, which deactivates CB,, from 
accessing the MEC network for a predefined time (X-days). 


Algorithm 8: Penalty function E3 

Algorithm code: E3. 

Description: Monitoring cloud broker actions. 
Executed by CSM. 

1. Input: E3 CB,- 

2. Output: W1 CB, or W2 CB, or system temporarily block for CB,. 
3. CSM: 7 7 

4 generate E3 CB, 

Dis count E3 CB,++ 

6. if  §E3 CB, =1 then 

7 generate W1 CB, 

8 CSM>CB,: W1_ CB, 

9 elseif E 

1 E3 CB, =2 

1 


0 
1 generate W2_CB, 
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2. CSM>CB,: W2 CB, 

3a else 

14. generate E4 CBy, 

Dis CSMDCB,: E4 CBy, 

6. CSM: performs system temporarily block from the network of CBy, for X- 
days 

17. requests all stored (E, (A,SLAjg_R) CSMp,) from CBy, 

8. CSM PNP, (CBy): requests new CBy selection || My, 

Jy where M,=[compromised CB,,;] 

20. NP, (CB,): selects nearby CBy 

21, NP„ (CBy)> CBuz: Mx 

22; NPy (CBy)>CSM: newly selected CBy 

23. CBu2? Sr; & SUj:broadcasts My 

24. endif 

25.end 


In case of CB, deactivation, CSM requests from the involved network provider to find a subsequent 
cloud broker and delegates all its functions to the newly selected cloud broker, which continues all the 
pending jobs. It also broadcasts a warning message (M,) to all surrounding service providers and users, to 
inform them of the compromised CB,,. As shown, the penalty functions update the participating entities in 
case a malicious participant is discovered, where this entity is banned from accessing the MEC network. This 
optimizes the security of interactions on the MEC network. 


2.6.5. Trust computational algorithms 

Figure 4 shows the processing performance computation steps of Sr;. Upon completion of function 
F2 by the cloud broker, the processing performance evaluation of Sr;, function F4 presented in algorithm 9, is 
executed by the CSM per computational interval, given that “A > 0” (Sr; had received jobs). In case a service 
provider is working with more than one cloud broker, CSM could authenticate each provider by its unique 
identity. Function F4 calls two other functions; function F3 (algorithm 10) for processing throughput 
computation, and function F5 (algorithm 11), that evaluates service provider trust status. 


Compromised 
Processing performance CB, 9 “nN 
evaluation- Function F4 e , f Warning or block 
7 for CB,, 


Function-F2 
Sends (A, SLA;,, Rn) for Trust computation 


CSM computes 
STi age: Pav (Sri), PI(Srj), 
UTR(Sr;), P(Sr;) 


Returns computed 
(En (PT(Sr;), Pay (Sri), P(Sr;), PI(Sr:), UTR(Sr;), 
T,(St;)) Srip,,) & (En (P(Sr;), Ta(Sr;)) CB upu) 


Compute PT(Sr;) 


PT(Sr;) 


(En (PT(Sr;), Pav (STi), 
P(Sr;), PI(Sr;), T, (Sr) 
UTR(Sr;), Ty(St;)) STip,) 


Compute T,,(Sr;) 


Figure 4. Processing performance computation function-F4 


Trust evaluation and all its parameters are evaluated by the CSM for three main reasons: 1- to 
ensure accurate and fair trust computation for service providers, 2- to guarantee service provider data security 
and confidentiality, 3- it helps service requesters to reveal trust values remotely prior starting their 
interactions. Sr; age is computed to show its processing lifetime in the MEC network. Trust computation 
begins by computing Pe, _T, Pe2_T, Pra_T, Pr2_T. Each of these parameters indicates the final status per 
process “a” received by Sr;. While the computed time difference TR;, = 0, the average processing success 
rate Pyy (Sr;) is computed. This is because there could be successful processes, in spite that Sr; had exceeded 
the estimated agreed time SE;,, but the service user had been patient enough. Therefore, this case is not 
considered as a fully successful job and could indicate that the predetermined processing capacity is not 
accurate for this Sr;. However, this raises the processing throughput value for Sr; computed by function F3, 
algorithm 10. 
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While the processing incompliance PI(Sr;) and user termination ratio UTR(Sr;) are computed, in 
case UTR(Sr;) exceeds user termination threshold, a warning is generated and sent to the relevant Sr; via the 
CB,,. This is to alarm Sr; of its high user termination ratio. Consequently, the processing performance P(S7;) 
is computed, then function F5 is executed, to get Sr; trust status. These results are encrypted by CSM and 
sent to Sr; via its CB,,. Processing throughput computation, function F3 (algorithm 10), is computed based on 
the number of successful processes P,,_T executed by S7;, (equation (6)). Based on the computed processing 
performance P(Sr;), Sr; is assigned one of six trust states by function F5, as shown in algorithm 11. 


Algorithm 9: Processing performance computation-function F4 
Algorithm code: F4. 

Description: Processing performance computation function. 
Executed by CSM. 


1. Input: (En (A, SLAjg_Rn) CSMp,) + Ydig 
2. Output: P(Sr;) computed 
3. CB,OCSM: batch of (En (A, SLAia Rn) CSMp,,) + Ydig 
4. CSM: 
Be decrypt (En (A, SLAjg_Rn) CSMp,) 
6. if Ydjg exceeded last day of month then 
Te execute Penalty function E3 
Bis endif 
ioe if Ydjig2 Pa,_last then 
0. for a=l to A 
Tse compute 
2; Pgı_T, Pgz T, Pra_T, Pr2_T, 
3.5 Stiage= Current_date - STi birth 
4. if Py, T 21 then 
5. execute Function F3 // compute PT(Sr;) 
6. if TRig 2 0 then 
7. compute Pry (Sr;) -fot // equation (3) 
Bro endif 
J; elseif Ppẹ_T2 1 or Py _ T 2 1 
20. compute PI(Sr;) = Sette // equation (4) 
21s elseif Pr T21 
22; compute UTR(Sr;) = Ent // equation (5) 
2335 if UTR(Sr,;) 2 user termination threshold then 
24. generate W1_Sri 
25 CSM> CB,: W1_ Sr; 
26. CB, >Sr;: W1_Sri 
27. endif 7 
28; else 
29°. PT(Sr;)=0, Pyy(S7)=0, PI(Sr;)=0, UTR(Sr;)=0 
30. endif 
alte endfor 
oes else 
33:5 CB,=compromised 
34. execute Penalty function E3 
3D 4 endif 
36. compute P (Sri) // equation (7) 


37. execute function F5 
38. CSM>CB,: (En (PT(Sr;), Pay (Sri), P(Sr;), PI(Sri), UTR(Sr:i), Ty (Sri)) S%p,) & 


39: (En (P (Sri), Tn (Sri)) CBupu) 
41. CB,>Sr;: (En (OTST), Pay (Sri), P (Sri), Pl(Sr;), UTR(Sr;), Ta (Sti)) Stip,,) 
42. end 


Algorithm 10: Processing throughput computation-function F3 

Algorithm code: F3. 

Description: Processing throughput computation function. 

Executed by CSM. 

1. Input: Py T. 

2. Output: PT(Sr;i) // processing throughput computation per computational interval for 


elseif (PE, T < 100,000) then 
On7 


Sri. 
3s COM + 
4. if (Pa T < 5,000) then 
Dis, Points (Sr;) = Ceil (Pg, T/10,000) 
6. elseif (PE, T < 10,000) then 
T Points (Sr) = 0.6 
8. 
9p 


Points (Sr;) 
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0. elseif (PR, T < 1,000,000) then 

1.3 Points (Sr) = 0.8 

23 else if (PR, T < 10,000,000) then 
3:5 Points (Sr) = 0.9 

4. else 

Da Points (Sr) = 1 

6. return PT(Sr;)= Points (Sr;) 

Fi endif 

8. end 


Algorithm 11: Trust status computation algorithm-function F5 
Algorithm code: F5. 

Description: Trust status computation function. 

Executed by CSM. 

1. Input: P(Sr;) 

2 Output: T, (Sri) 

3 CSM: 

4 If P(Sr;) <0 then 

5. Ta (Sr;)= “untrusted service provider” 
6 elseif P(Sr;) < 0.3 then 

7 Ta (Sr;)= “weak service provider” 
8 elseif P(Sr;) < 0.5 then 

9 T, (Sr;)= “average service provider” 


0. elseif P(Sr) < 0.7 then 

1x Ta (Sr;)= “good service provider” 

2. elseif P(Sr;) < 0.9 then 

3. Tn (Sr;)= “very good service provider” 
4. else 

Js Ta (Sr;j)= “ excellent service provider” 
6. endif 

7. return T, (Sri) 

8. end 


Upon the completion of the above functions, each service provider will be assigned a trust status 
based on its computed processing performance value. This trust status disseminates service provider’s 
processing performance during its service provisioning in the MEC network. 


3. RESULTS AND DISCUSSION 

Simulation results of the proposed architecture are shown in section 3.1, while the efficiency and 
effectiveness of proposed scheme are discussed in section 3.2. Section 3.3 presents a comparison between the 
proposed architecture and some previous protocols. 


3.1. Simulation results 
Simulation of the proposed model was performed using MATLAB program. Simulation setup: 
— five different service providers were considered, Sr; = {1,2,3,4,5}. 
— initial trust value for each Sr;= zero. 
— all Sr; received the same number of job requests, in one job_type{Job3}, from various service users. 
— computation intervals = 5 (1 month duration each) 
— Pga_T, Pg2_T, Pra_T, Pr2_T values: were assigned to each Sr; according to uniform random number 
generation per month. 
— hardware PC configuration = core i7, RAM 6 GB and hard disk | Tera. 

Trust evaluation was performed over the five months. Sr; is evaluated according to its processing 
performance in its predefined job type. The processing throughput PT(Sr;) results for each service provider 
per “m” month are shown in Figure 5. While the average processing success rate Pay (Sr;) results are given 
Figure 6. 

Upon measuring the processing throughput and average success rate, the processing performance 
P(Sr;) is computed as presented in Figure 7 and the relevant trust status per Sr; over the five months, is 
shown in Table 3. Figure 8 reveals the processing incompliance (failure ratio) PI(S7;) and Figure 9 shows the 
user termination ratio per S7;. Results show that service providers 1 and 2, trust status had improved 
gradually by time, because of their improvement in terms of processing throughput and average processing 
success rate over the five months. With this improve, processing incompliance and user termination ratio, had 
decreased as shown Figures 8 and 9. Service provider 3 trust status kept varying by time, within a good to 
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average range. While service provider 4 maintained its good trust status over the five months, however its 
processing incompliance acts as a major drawback as illustrated in Figure 8. Service provider 5, kept its 
excellent processing performance over the five months since its processing incompliance and user 
termination ratio are very low. Thus, simulation results could identify the processing performance of all five 
service providers, together with their processing incompliance and user termination ratios, showing their 
respective trust status. 


3.2. Efficiency and effectiveness of the proposed architecture 

Analysis of the proposed architecture shows that the evaluation time is considerably low, due to the 
simplicity of the used equations. Processing performance evaluation and trust status results are updated 
periodically by CSM (fully trusted entity), which increases results credibility. In addition, maintaining a 
history record decreases service provider trust evaluation time, since it’s performed in an accumulative 
manner. A service provider is registered only once to the MEC network using its unique credentials. This 
encounters attacks such as fake or malicious service providers, who could deceive users by hiding their bad 
history. 

As the number of service providers increases, the proposed architecture could still distinguish each 
service provider using its assigned trust status and processing performance value. This validates service 
providers’ computational services trust level and history in the MEC network, which promotes for trusted and 
secured transactions. A service user is also given a recommendation list of available service providers to 
choose from, according to user’s computational requirements and preferences. 


3.3. Comparison with previous protocols 
Table 4 shows a comparison of the proposed architecture evaluation parameters with previous 
works. The major limitations/discussion for each one of them. 


PROCESSING THROUGHPUT AVERAGE PROCESSING SUCCESS RATE 


ogee S11 ome S12 oe S13 mpg S14 mete Sr5 ee Sr] =i S2 =i S3 = Sr eee Sr5 
1.20 


0.9 1.00 
0.8 


Figure 5. Processing throughput per service provider Figure 6. Average processing success rate per 
service provider 
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Figure 7. Processing performance per service provider 
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Table 3. Trust status per service provider in “m” months 
Sr; M1 M2 M3 M4 M5 
Sri Weak Weak Average Good Good 
Sr, Average Good Good Very good Very good 
Srůr3 Good Average Good Good Average 
Sry Good Good Good Good Good 
Sr, Excellent Excellent Very good Very good Very good 
PROCESSING INCOMPLIANCE USER TERMINATION RATIO 
-t S] jj S2 i Sr3 eee Sr4 =y Sr5 =S =S =r S3 = S4 = S55 
0.70 aro 
0.60 
0.10 
0.50 
0.08 
0.40 
0.06 
0.30 
0.20 0.04 
0.10 0.02 
0.00 0.00 
M1 M2 M3 M4 M5 M1 M2 M3 M4 M5 


Figure 8. Processing incompliance per service provider Figure 9. Service providers’ user termination ratio 


Table 4. Comparison of the proposed architecture and previous work 


Service Provider Assessed Evaluation Trust Update Saneas : A 
Protocol A : ; Limitations/Discussion 
Parameters Domain Static | Dynamic 

[17] Security methods applied in Computation- Did not consider sudden attacks that could 

2018 terms of: i) authentication, ii) based occur to a node, such as hacking. 
firewall systems; iii) y 
encryption mechanisms, iv) 
intrusion detection 

[18] Performance in terms of: Reputation- V Depended only on users’ opinions. 

2020 -identity authentication based Collusion attack may occur. 
-hardware capabilities (Direct/indirect 
-interactions’ behavior trust) 

[19] Performance in terms of: Feedback- Partial Trust computation is performed by an 

2018 -identity authentication based & unknown entity, which makes trust results 
-capabilities (availability, computation- sharing difficult. 
response time, throughput, based Trust computation is complicated and time 
deployed hardware) consuming. 

-interactions’ behavior 
[20] Analyze traffic flows between Computation- V No processing parameters are evaluated. 
2018 two communicating entities. based 
Proposed Processing performance in Computation- V No human interaction involved, which 
Protocol terms of: based guarantees results credibility. 

2020 -processing throughput History capturing decreases computational 
-average processing success overhead and limits re-register attack. 
rate Dynamic updating of results shows recent 
-processing incompliance trust status of a service provider in the 
-user termination ratio. MEC network. 

Proposed a penalty system to track 
malicious entities. 
4. CONCLUSION AND FUTURE WORK 


Trust was evaluated by computing the processing performance of a service provider, through 
gaining its average processing success rate and processing throughput. However, processing incompliance 
and user termination ratio were computed, to accurately determine service providers’ performance in the 
MEC network. The proposed penalty system provided a close monitoring to the participating entities in the 
MEC network. By capturing the historical trust results, there is no need to evaluate a service provider trust 
status before the start of each interaction. Thus, gaining accurate and fair trust results with less computation 
overhead and minimal human interference. 
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Simulation results showed that, the higher average processing success rate and throughput, the better 
processing performance and trust status evaluation gained for a service provider. On the other hand, results 
illustrated that high processing incompliance or user termination ratio, are reflected in a low processing 
performance value for a service provider. Thus, maintaining service users’ reliability and securing future 
interactions in the MEC environment. For future work, we plan to evaluate service providers’ deployed 
hardware and software resources. In this context, security measures, scheduling algorithms, fault tolerant 
protocols deployed by a service provider should be considered during trust evaluation. On the other hand, the 
number and types of warnings imposed on a service provider, due to performing unauthorized actions should 
also be considered and analyzed in the future. Given that all acting entities are registered in the network 
through the network provider, a network provider could act as a cloud broker or even a service provider. On 
the other hand, a cloud broker could also act as a service provider. However, it will be recommended to 
review the trust evaluation parameters for these acting entities. 
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